1. Technical Field of the Invention
The present invention relates to telecommunications, and particularly to transfer of policy information in 3GPP networks.
2. Description of Related Art
FIG. 1 shows a block chart of a prior art telecommunication network 100 that will be used to describe the prior art and the problem solved by the present invention.
The telecommunication network 100 is to at least a certain extent a Third Generation Partnership Project (3GPP), as for example a core network 102 in connection with three access networks 104, 106 and 108, via a gateway (GW) each 114, 116 and 118, respectively. In 3GPP different kinds of access networks, such as for example GPRS, packet cable and UMTS, may share the same core network and the access networks are to a high degree transparent as to data packets sent from the core network to devices in the access network, and carrying Session Initiation Protocol (SIP) information. In network 3 106, that in this example is a GPRS/UMTS network, there is a terminal A 120 that is used by user A (not shown), and the gateway 116 is a Gateway GPRS Serving/Support Node (GGSN). In addition, the core network 102 comprises a number of routers 110 that routes data packets sent through the core network 102 towards the intended recipients.
The core network 102 is connected to other networks, such as to A's home network 130 through a Proxy Call State Control Function 122 (P-CSCF) for SIP signalling via connection 126, and to network 140 (B network), for data traffic via connection 128. A terminal 142 used by user B (not shown) resides in the B network 140. The P-CSCF 122 comprises an IP Policy Control 124 (IPPC) and A's home network 130 comprises a Serving Call Session Control Function 132 (S-CSCF). The function of these nodes will be described hereinafter. Furthermore, there is also a connection 134 between A's home network 130 and the B network 140.
In the following explanatory scenario it is assumed that user A desires to contact user B, via their respective terminals 120 and 142. Terminal A 120, a GPRS capable terminal, has access to the access network 106 and has been allocated an IP address as result of a Packet Data Protocol (PDP) Context activation procedure. This IP address is one of the IP addresses that ‘belong’ to the access network 106 and the IP address is used to send data to the device 120. Each access network is assigned a group of, usually consecutive, IP addresses, and the groups are disjunct from IP addresses used by other access networks.
To set up a connection with terminal B 142, terminal A sends a SIP message to the P-CSCF 122 through a low bandwidth channel (not shown), transparently via the GGSN 116, giving the user identity, such as the phone number, of terminal B 142. The P-CSCF 122, contacts the S-CSCF 132 in A's home network 130. The S-CSCF 132 in turn contacts the B network 140 in order to contact terminal B 142. It should be noted that the B network 140 need not be a 3GPP network, and that the exact method of contacting terminal B 142 thus may differ. At this point there is a control signalling path (not shown) from terminal A 120 to terminal B 142
During or after this contacting procedure, a bearer is reserved between the GGSN 116 and the B network 140. This bearer takes another route than the signalling path, normally the shortest (or cheapest) way to terminal B 142, which in this case is through the core network 102—possibly via a number of routers 110—and connection 128 directly to the B network 140 and from there to terminal B 142.
When user B accepts the incoming call, a response message, such as for example a Session Initiation Protocol (SIP) “200 OK” message, is propagated towards the P-CSCF 122. When this message reaches the P-CSCF 122, it informs the IPPC 124 that the reserved bearer can be “opened”. The IPPC 124 then sends an order to the GGSN 116 to allow terminal A to send traffic data packets, such as speech data, through the bearer to terminal B 142. The two users may then continue to send data packets until it is decided to terminate the connection, at which point a Disconnect message is sent the same way as the response message hereinbefore, finally resulting in that the GGSN 116 thereafter denies terminal A 120 any use of the bearer.
Thus it should be clear that signalling packets and traffic packets follow different routes through the network 100. A problem with this separation of routes is that there is a need for some interaction between the signalling path and the bearer for SIP sessions that require a special Quality of Service (QoS) better than “best effort”. This is to ensure that the signalling path and the bearer correspond to each other in order to e.g. prevent denial of service attacks and theft of service. Another reason is that the gateway needs to be certain that the bearer is only used as allowed; a user is charged only when a call is active, i.e. between the time when it is accepted and the time it is disconnected, and a user should not be allowed to send any traffic data packets outside this time frame, as he would not be billed for them.
The aforementioned interaction is provided by the IPPC 124 that acts as a Policy Decision Point (PDP) and the gateway that acts as a Policy Enforcement Point (PEP). This is to say that the PDP decides the access policy that should be used and sends the policy to the PEP that enforces it, e.g. by allowing or denying a device access to the core network. A preferred protocol for communication between the PDP and the PEP is the Common Open Policy Service Protocol (COPS) and the 3GPP standard specifies that information should be ‘pushed’ to the recipient, i.e. sent to the recipient without first having been asked for the information.
Using the PDP and the PEP, the PDP (IPPC 124) receives from the P-CSCF 122 the necessary information to validate a request for a certain QoS. It then pushes its decision to the relevant PEP that resides in the gateway. However, the only information about a user's whereabouts available to the P-CSCF 122 and the IPPC 124 is the user's IP address, so the PDP must have a way of knowing which PEP is the relevant one. There is currently no known way the PDP can know this, at least not in an environment where a PDP is in contact with more than one PEP.
Furthermore, the information about which PEP is the proper PEP is dynamic. If a gateway is out of service another PEP should preferably be used instead. Thus the IP addresses previously reached through a certain PEP (with address x) could be reassigned to another PEP (with address y). In addition, enabling multiple PEPs is needed to allow load sharing, redundancy, etc.
It can therefore be appreciated that there is a need for a solution that solves this problem of knowing to which PEP the PDP should push information. This invention provides such a solution.